%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% All whales pull rainy, cold girls.
% Death, life, and desolation.
% The sea grows like a warm sun.
% Where is the stormy sailor?
% Golly gosh, death!

\documentclass{l3deliverable}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\usepackage{graphicx}%
%
\usepackage{svn-multi}%
\svnid{$Id: d8_4.tex 2500 2011-09-21 15:56:43Z tws $}

\version{78}

\usepackage{tabularx}%
\usepackage{url}%
\usepackage{testcasedescription}%
\ifx\pdftexversion\undefined
\usepackage[dvips]{graphicx}
\else
\usepackage[pdftex]{graphicx}
\DeclareGraphicsRule{*}{mps}{*}{}
\fi
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Check these macro values for appropriateness for your own document.
% I'm a little teapot
% short and stout..

% here is my handle ->
\title{Maintenance Report}
\titlesmall{Maintenance Report}
% here is my spout ->
\author{
  Daniel Callander \\
  Agnieszka Kielbinska \\
  Stephen McQuistin \\
  David Newall \\
  Ian Scott}

\date{5 March 2012}

\deliverableID{D8.4}
\project{PSD3 Group Exercise 2}
\team{K}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{document}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\maketitle

\tableofcontents

\newpage

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Standard section for all documents

\section{Introduction}

\subsection{Identification}

This is Team K's Maintenance Report for the DemoSOCS project.

\subsection{Related Documentation}

\begin{description}
  \item[Group Exercise 2 overview document] \hfill \\
	\url{http://fims.moodle.gla.ac.uk/mod/resource/view.php?id=18599}
  \item[Group Exercise 2 DemoSOCS Requirements Specification] \hfill \\
  \url{http://fims.moodle.gla.ac.uk/mod/resource/view.php?id=18596}
  \item[Group Exercise 2: D8.4] \hfill \\
	\url{http://fims.moodle.gla.ac.uk/file.php/128/ge-2-d8.4-rev2927.pdf}
\end{description}

\subsection{Purpose and Description of Document}

The purpose of this document is to outline, in detail, the componentized design of the system, through the use of component and class diagrams. In addition, the document outlines the test cases which form our acceptance test plan. This plan has been designed to ensure that each class and component of the system works as desired in reference to the requirements specification. 

\subsection{Document Status and Schedule}

This is release 78, dated 1/3/12. This is the final redraft of this document, and incorporates feedback provided for the draft deliverable D6, and design changes made as a result of implementation of the system.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{System Design}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\subsection{Components and component diagram}

\begin{center}
\begin{figure}[h!]
	\centering
\includegraphics[scale=0.8]{img/comp_diag.1}
\caption{Component diagram}
\end{figure}
\end{center}

This component diagram shows our system architecture. We have split the voting system into five distinct components. These components connect to each other via facades, proving maximal cohesion and minimal coupling: a given component does not know how a connected component is implemented, only that it provides specified functionality. Our components are:

\begin{description}
\item[CLUI] \hfill \\
This component provides a command-line user interface, and is handles all interactions with the user. This component utilises the \textbf{VotingSystem} interface provided by \textbf{ElectionManager} and its subcomponents, via which it can complete any of the functionality described within the implemented use cases, but does not provide any functionality on its own. It should be noted that while our implementation includes a CLUI, by the nature of the facade pattern, anything which makes use of the \textbf{VotingSystem} interface can plugin to \textbf{ElectionManager}. This could include a GUI, as part of further development, or a test harness.
\item[UserManager] \hfill \\
This components provides user authentication functionality which allows us to easily validate a particular username and password. The implementation is already provided from the school, allowing us to easily connect it to the \textbf{ElectionManager} through its facade. Modifications have been made to the provided component to allow for recognising that only election managers may manage elections. Again, the flexibility of the facade design pattern allows this component to be replaced with another, say a functional MyCampus authentication wrapper, as long as the \textbf{UserStore} interface is provided.
\item[ElectionStorage] \hfill \\
This allows \textbf{ElectionManager} to save its elections to some physical storage via the provided interface. This was moved to its own component, as it allows us to separate the concerns of storing elections from the internal workings of the voting system. It may have made more sense to make this a subcomponent of \textbf{ElectionManager}, but this design was kept to make the design as general, and so as reusable, as possible.
\item[ElectorateStorage] \hfill \\
This allows \textbf{ElectionManager} to save the electorates to some physical storage via the provided interface. While it should be noted that \textbf{UserManager}, \textbf{ElectionStorage} and \textbf{ElectorateStorage} share similar functional properties and could be generalised to provide generic persistent storage, we believe that there may be different non-functional requirements associated with the various categories of storage. For example, more security concerns exist when storing user information, than other types.
\item[ElectionManager] \hfill \\
This component and its subcomponents, \textbf{Nominations} and \textbf{Elections}, provide the actual election functionality. That is, they provide functionality for key tasks, such as voting, creating elections and handling nominations.

\end{description}
	
\subsection{Component class diagrams}
\subsubsection{CLUI}
\begin{center}
\begin{figure}[h!]
	\centering
\includegraphics[scale=0.8]{img/controller_class.1}
\caption{Controller class diagram}
\end{figure}
\end{center}
This class diagram shows the workings of the \textbf{CLUI} component. It provides a CommandLineUI$<$VotingSystem$>$ class which would generally be the applications main entry point and implements all use cases. It has a unidirectional relationship to some object that implements the VotingSystem interface from which it can implement that functionality. The CommandLineUI$<$Facade$>$ class is part of the UI and CLUI packages provided by the school, and we do not think that further documentation of these packages would aid in the understanding of the structure of our system. Essentially, the CommandLineUI$<$Facade$>$ can be replaced by any code which makes use of the \textbf{VotingSystem} interface.

\subsubsection{UserManager}
\begin{center}
\begin{figure}[h!]
	\centering
\includegraphics[scale=0.8,angle=90]{img/usermanager_class.1}
\caption{UserManager class diagram}
\end{figure}
\end{center}
This (figure 3) is the class diagram for the \textbf{UserManager} component. An interface UserStore is provided which is implemented by UserStoreImpl. UserStoreImpl keeps track of all Users, stored in a file, and allows for the authentication of users.

\subsubsection{ElectionManager}
\begin{center}
\begin{figure}
	\centering
\includegraphics[scale=0.4,angle=90]{img/electionManager.1}
\caption{ElectionManager class diagram}
\end{figure}
\end{center}
In this (figure 4) diagram we have the central class of VotingSystemImpl. This is the class that implements the voting system interface. This is effectively the core system that manages all the other classes. All the other classes provided functionality to this such as a means of storage or representing entities. It is this class that does all the internal processing for example setting up an election or deleting an election or casting a vote. It was implemented this way as it was the easier way to realise the facade interface that we have been supplied with. As within the facade the Voting System interface was the core component. So in order to realise the facade we implement all of the facade interfaces as classes and used other classes to supply the functionality.

\subsubsection{ElectionStorage}

\begin{center}
\begin{figure}[h!]
	\centering
\includegraphics[scale=0.8]{img/persistent_class.1}
\caption{ElectionStore class diagram}
\end{figure}
\end{center}

This (figure 5) shows the interface implemented by ElectionStoreImpl. This provides functionality for adding and removing elections from some, abstracted, physical storage medium. By abstracting in this way, it is possible to change the way in which elections are stored, without any further changes to the system.

\subsubsection{ElectorateStorage}

\begin{center}
\begin{figure}[h!]
	\centering
\includegraphics[scale=0.8]{img/estore_class.1}
\caption{ElectorateStore class diagram}
\end{figure}
\end{center}

This (figure 6) shows the interface implemented by ElectorateStoreImpl. This provides functionality for adding electorates, and adding and removing users from these electorates. In addition, it is possible to check if a user is part of an electorate using a simple method call. This functionality is abstracted to allow for changes in how electorates are stored within the system. As noted earlier, allowing for different abstractions of common persistent storages enables flexibility within the non-functional requirements of the different objects being stored.

\subsection{Design and Development Process}

The overall aim, in line with software engineering best practice, of the system design is to enable code reuse, by adopting a design which makes use of several discrete components, with well defined interfaces. This enables individual components to be swapped out entirely, and for components with different implementations of the same interface to replace them. 

The flexibility offered by this method is best demonstrated in our use of three different storage classes for elections, electorates and users. This may appear to be overengineering, given that these share the common need of being persisted in some way. However, by providing three different store interfaces, these can be unified should it be decided that a common \textbf{PersistentStore} is viable.

In addition, by adopting the facade design pattern, we enable testing to be conducted on this facade rather than on specific implementation details. This allowed for an implementation swap to be conducted, and for test cases which were developed without \textit{any} implementation details to be run against our code.

Our development process was to split the discrete components of the system, with individuals given the responsibility of implementing a given component. This allowed us to ensure that coupling was minimised, by highlighting where components were overly dependent on each other. 

\subsection{System API}

The API for classes which we have implemented, rather than the API for the facade provided, is given below. 

\subsubsection{CandidateImpl.java}
\begin{description}
	\item[Full name] \hfill \\
		public class CandidateImpl
	\item[Package] \hfill \\
		uk.ac.glasgow.demosocs.impl
	\item[Description] \hfill \\
	Concrete implementation of a Candidate interface that provides information about a candidate in an election.
	\item[Implements] \hfill \\
	uk.ac.glasgow.demosocs.Candidate;
	java.io.Serializable;
	\item[Author] \hfill \\
	Team K
	\item[Methods] \hfill \\
	\begin{description}
		\item[public CandidateImpl(String guid)] \hfill \\
		Constructor, taking a GUID and constructing a new candidate. Other fields, such as the surname and forename are populated from the UserStore.
		\item[public String getGUID()] \hfill \\
		Returns the candidate's GUID.
		\item[public String getCandidateSurname()] \hfill \\
		Returns the candidate's surname.
		\item[public String getCandidateForename()] \hfill \\
		Returns the candidate's forename.
	\end{description}
\end{description}

\subsubsection{ElectionImpl.java}
\begin{description}
	\item[Full name] \hfill \\
		public class ElectionImpl
	\item[Package] \hfill \\
	uk.ac.glasgow.demosocs.impl
	\item[Description] \hfill \\
	Concrete implementation of an Election interface which provides access to common information about election instances.
	\item[Implements] \hfill \\
	uk.ac.glasgow.demosocs.Election.java
	java.io.Serializable
	\item[Author] \hfill \\
	Team K
	\item[Methods] \hfill \\
		\begin{description}
	\item[public ElectionImpl(String name, String typeID)] \hfill \\
		Constructor that takes the election's name and the election’s type id as parameters.
		
	\item[public void editElectionImpl(Date openN, Date start, Date end, String eeID)] \hfill \\
		Edits an election, setting the relevant election information.
		\item[public String getType()] \hfill \\
 		Gets the type ID.
		\item[public String getElectorateID()] \hfill \\
		Gets the electorateID.
	\item[public Set$<$User$>$ getNominations()] \hfill \\
		Returns a set of users which are nominees.

	\item[public HashMap$<$String, Integer$>$ getVotes()] \hfill \\
		Returns a hashmap of votes, key being the GUID and value being number of votes.

	\item[public void setElectionResult(ElectionResult er)] \hfill \\
Sets the election result to the one supplied. Takes an election result er as a parameter. 
 	
	\item[public void setOpenNominations(Date onDate)] \hfill \\
Sets the date nominations open. Takes date as a parameter.
	
	\item[public void setStart(Date startDate)] \hfill \\
		Sets the start date.

	\item[public void setEnd(Date endDate)] \hfill \\
		Sets the end date.

	\item[public void setElectorateId(String electorate)] \hfill \\
		Sets the electorate ID.

	\item[public boolean nominationsOpen()] \hfill \\
		Returns true if elections are open, false otherwise.
	
	\item[public void addVote(String guid)] \hfill \\
		Adds a vote for the supplied candidate GUID. Takes the GUID of a candidate to vote for as a parameter.
	\item[public void addNomination(User u)] \hfill \\
		Adds a user as a nominee. Takes user u as a parameter.
	\item[public void addCandidate(Candidate c)] \hfill \\
		Adds a user as a candidate. Takes candidate c as a parameter.
\end{description}
\end{description}

\subsubsection{ElectionResultImpl.java}
\begin{description}
\item[Full name] \hfill \\
	public class ElectionResultImpl
\item[Package] \hfill \\
	uk.ac.glasgow.demosocs.impl
\item[Description] \hfill \\
	Concrete implementation of an ElectionResult interface.
\item[Implements] \hfill \\
	uk.ac.glasgow.demosocs.ElectionResult
\item[Author] \hfill \\
	Team K
\item[Methods] \hfill \\
	\begin{description}
	\item[public ElectionResultImpl(List$<$Candidate$>$ winners)] \hfill \\
		Constructor with a list of winner as a parameter.
	\end{description}
\end{description}

\subsubsection{OneOfNVoteStub.java}
\begin{description}
\item[Full name] \hfill \\
	public class OneOfNVoteStub
\item[Package] \hfill \\
uk.ac.glasgow.demosocs.impl
\item[Description] \hfill \\
	Concrete implementation of OneOfNVote interface
\item[Implements] \hfill \\
	uk.ac.glasgow.demosocs.OneOfNVote
\item[Author] \hfill \\
	Team K
\item[Methods] \hfill \\
	\begin{description}
	\item[public OneOfNVoteStub(String candidate)] \hfill \\
		Constructor
	\item[public String getCandidateGUID()] \hfill \\
		Returns the GUID of the candidate.
\end{description}
\end{description}

\subsubsection{VotingSystemImpl.java}
\begin{description}
\item[Full name] \hfill \\
	public class VotingSystemImpl
\item[Package] \hfill \\
uk.ac.glasgow.demosocs.impl
\item[Description] \hfill \\
	Concrete implementation of VotingSystem interface
\item[Implements] \hfill \\
	uk.ac.glasgow.demosocs.VotingSystem
\item[Author] \hfill \\
	Team K
\item[Methods] \hfill \\
	The methods implemented in this class reflect only those within the implemented interface - there are no additional methods. 
\end{description}

\subsubsection{UserStoreImpl}
\begin{description}
\item[Full name] \hfill \\
	public class UserStoreImpl.java
\item[Package] \hfill \\
	uk.ac.glasgow.demosocs.users
\item[Description] \hfill \\
	Concrete implementation of the UserStore interface.
\item[Implements] \hfill \\
	uk.ac.glasgow.demosocs.users.UserStore
\item[Author] \hfill \\
	tws (modified by Team K)
\item[Methods] \hfill \\
	\begin{description}
	\item[public UserStoreImpl(String fileName)] \hfill \\
		Constructs a new store in the specified file location. Takes the name of the file as a parameter.
	\item[public void storeUser(String GUID, User u)] \hfill \\
		Writes user details into a store file.
	\item[public User getUserWithGUID(String GUID)] \hfill \\
		Gets a user via their GUID. Takes the user’s GUID as a parameter and returns a user.
	\end{description}
\end{description}

\subsubsection{ElectionStore.java}

\begin{description}
\item[Full name] \hfill \\
	public interface ElectionStore.java
\item[Package] \hfill \\
	uk.ac.glasgow.demosocs.electionstore
\item[Description] \hfill \\
	Provides a means for storing details of every election, such as election id and type, elecotarate id, as well as start and end date of the election and start date of nomination for this election. 
\item[Author] \hfill \\
	Team K
\item[Methods] \hfill \\
	\begin{description}
	\item[public void addElection(String id, String type)] \hfill \\
	Adds a new election to the election store.
	\item[public Election getElection(String id)] \hfill \\
	Returns the election represented by the election ID 'id'
	\item[public Set$<$Election$>$ getElections()] \hfill \\
	Returns all elections stored in the system.
	\item[public void editElection(String electionId, Date openNominations, Date start, Date end, String electoratelectionID)] \hfill \\
	Edits the election stored with electionId, changing the relevant fields.
\end{description}
\end{description}

\subsubsection{ElectionStoreImpl.java}	
\begin{description}
\item[Full name] \hfill \\
	public class ElectionStoreImpl
\item[Package] \hfill \\
	uk.ac.glasgow.demosocs.electionstore
\item[Description] \hfill \\
	Concrete implementation of the ElectionStore interface.
\item[Implements] \hfill \\
	uk.ac.glasgow.demosocs.electionstore.ElectionStore
\item[Author] \hfill \\
	Team K
\item[Methods] \hfill \\
	In addition to the methods listed below, all of the methods defined in the ElectionStore interface are realised.
	\begin{description}
	\item[public ElectionStoreImpl(String fileName)] \hfill \\
		Constructs a new store in the specified file location. Takes the name of the file as a parameter.
	\item[public void storeElection(String id, ElectionImpl election)] \hfill \\
		Writes election details into a store file.
	\end{description}
\end{description}

\subsubsection{ElectorateStore.java}
\begin{description}
\item[Full name] \hfill \\
	public interface ElectorateStore
\item[Package] \hfill \\
	uk.ac.glasgow.demosocs.electoratestore
\item[Description] \hfill \\
	Provides a means for storing details of electorates, which maps which users are eligible to participate in which Elections as Candidates and Voters. Stores details such as electorate id and a set of users eligible to participate in the election.

	\item[Author] \hfill \\
	Team K
	\item[Methods] \hfill \\
		\begin{description}
		\item[public void addElectorate(String electorateID, Set$<$String$>$ users)]
	Add a new electorate to the store, with a set of users.
	\item[public void addElectorate(String electorateID)]
	Add a new electorate, with no users.
	\item[public void addUserToElectorate(String electorateID, String userID)]
	Adds userID to an electorate, specified by electorateID.
	\item[public void removeUserFromElectorate(String electorateID, String userID)]
	Removes userID from an electorate, specified by electorateID
	\item[public boolean isEligible(String electorateID, String userID)]
	Checks if userID is in the electorate specified by electorateID.
		\end{description}
	\end{description}
	
\subsubsection{ElectorateStoreImpl.java}	
\begin{description}
\item[Full name] \hfill \\
		public class ElectorateStoreImpl
\item[Package] \hfill \\
		uk.ac.glasgow.demosocs.electoratestore
\item[Description] \hfill \\
		Concrete implementation of the ElectorateStore interface.
\item[Implements] \hfill \\
		uk.ac.glasgow.demosocs.electoratestore.ElectorateStore
\item[Author] \hfill \\
		Team K
\item[Methods] \hfill \\
			In addition to the methods listed below, all of the methods defined in the ElectorateStore interface are realised.
			\begin{description}
		\item[public ElectorateStoreImpl(String fileName)] \hfill \\
			Constructs a new store in the specified file location. Takes the name of the file as a parameter.
		\end{description}
	\end{description}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\newpage
\section{Acceptance Test Plan}

\subsection{Testing strategy}
\subsubsection{Unit testing}

Classes will be divided amongst team members, and individual team members will be responsible for the unit testing of classes which they commit. These unit tests should be run successfully before new code is committed. If the testing is automated using JUnit, then these test should be committed along with the code.

\subsubsection{Regression testing}

The aim of regression testing is to ensure that our continued development of the system, be that the addition of new components or the fixing of existing ones, does not mean that previously passing tests now fail. Given the small nature of our project, and the largely automated nature of our acceptance tests, we have decided that these can be run after each commit.

Once these have been run, the person making the commit will review the results, and either take steps to fix the error (time permitting), to raise a code review for the component(s) where the tests are now failing, or, if the now broken feature is critical, to back-out the changes until the code has been reimplemented.

In addition to running our automated tests after each commit, time will be made each week to run all test cases, including manually executed ones. This will ensure that there is a minimal amount of time between changing the code, and checking for defects.

\subsubsection{Acceptance testing}

The aim of acceptance testing is to ensure that the system meets the system requirements, which we have gathered earlier in the project. We have developed test cases (listed in section 3.3, ``Acceptance Test Cases'') which test that a given requirement is fulfilled. Some requirements are tested using more than one test case.

\subsubsection{Testing Environment}

The test environment is the Level 3 Lab machines, running Fedora 13. JUnit 4 is used to run the automated test cases.
\subsection{Acceptance Test Demonstration Plan}

We have defined the roles of the demonstration to be: demonstrator, narrator and secretary. The role of the narrator will include answering questions from the stakeholder as they arise. The test data to be used will be the same as that which is defined in section 3.3.1, ``Common Test Data Set''.

The high priority use cases will be demonstrated first, in no particular order. Where it is convenient to do so, the order will be selected to ensure minimal resetting of the system, for example, a use case which destroys an election will be run after use cases such as viewing elections. This ensures that all high priority use cases can be covered during the demonstration.

Where time permits, after the high priority use cases have been demonstrated, the stakeholder will be permitted to use the system without our guidance. This will allow them to get their own feel of the flow of the application, and to test functionality which may not have been fully understood during the initial walkthrough.

The non-functional requirements are difficult to demonstrate. Where possible, these will be demonstrated. Where is cannot be done, given the time constraints, automated scripts will be used to demonstrate this.
 
\subsection{Acceptance Test Cases}

Our Acceptance Test Plan is formed through the test cases which follow. These test cases have been grouped on the use cases on which they are based. For each must-implement use case from the requirements specification, at least one test case has been developed.

\subsubsection{Common Test Data Set}

Elections are created and initialised by individual test cases, as defined in the ``Inputs'' section. Two users are set within the system 'admin' and 'user'. Both of these have passwords 'pass'. 'admin' is set as an election manager, and can therefore create and edit elections.

\newpage
\subsubsection{Schedule election}
\begin{TestCaseTemplate}
\TestCaseIdentifier{1.1}
\TestCaseUseCase{Schedule Election}
\TestCaseScenario{Primary}
\TestCaseSetup{ElectionManager is logged in}
\TestCaseInterface{uk.ac.glasgow.demosocs.Election.java}
\TestCaseIncludes{Edit Election}
\TestCaseProcedure{uk.ac.glasgow.demosocs.tests.ScheduleElection1.java}
\TestCaseInputs{Create a new election with ID 'l3reps', with start date as '12/2/2012' and the end date as '19/2/2012' and the nomination date '5/2/2012'.}
\TestCaseOutcome{A new election has been created, with the details as input.}
\end{TestCaseTemplate}
\newpage
\subsubsection{Edit election}
\begin{TestCaseTemplate}
\TestCaseIdentifier{2.1}
\TestCaseUseCase{Edit Election}
\TestCaseScenario{Primary}
\TestCaseSetup{An election with ID "l3reps" exists in the system.}
\TestCaseInterface{uk.ac.glasgow.demosocs.Election.java}
\TestCaseIncludes{}
\TestCaseProcedure{uk.ac.glasgow.demosocs.tests.EditElection1.java}
\TestCaseInputs{electionId = 'l3reps', date = '12/02/2012'}
\TestCaseOutcome{The date of the election 'l3reps' has changed to 12/02/2012.}
\end{TestCaseTemplate}
\newpage
\subsubsection{Open nominations}
\begin{TestCaseTemplate}
\TestCaseIdentifier{3.1}
\TestCaseUseCase{Open Nominations}
\TestCaseScenario{Primary}
\TestCaseSetup{An election with ID "l3reps" exists in the system.}
\TestCaseInterface{uk.ac.glasgow.demosocs.Election.java}
\TestCaseIncludes{}
\TestCaseProcedure{uk.ac.glasgow.demosocs.tests.OpenNominations1.java}
\TestCaseInputs{electionId = 'l3reps'}
\TestCaseOutcome{Nominations for the election 'l3reps' have opened.}
\end{TestCaseTemplate}
\newpage
\subsubsection{Start election}
\begin{TestCaseTemplate}
\TestCaseIdentifier{4.1}
\TestCaseUseCase{Start Election}
\TestCaseScenario{Primary}
\TestCaseSetup{}
\TestCaseInterface{uk.ac.glasgow.demosocs.VotingSystem.java}
\TestCaseIncludes{}
\TestCaseProcedure{Must be executed manually.}
\TestCaseInputs{date = '15/02/2012'}
\TestCaseOutcome{Date is set to 15/02/2012, and the election will start on this date.}
\end{TestCaseTemplate}
\begin{TestCaseTemplate}
\TestCaseIdentifier{4.2}
\TestCaseUseCase{Start Election}
\TestCaseScenario{Alternative}
\TestCaseSetup{}
\TestCaseInterface{uk.ac.glasgow.demosocs.VotingSystem.java}
\TestCaseIncludes{}
\TestCaseProcedure{Must be executed manually.}
\TestCaseInputs{date = '15/02/2012'}
\TestCaseOutcome{Date is set to 15/02/2012, but the election fails to be scheduled for this date.}
\end{TestCaseTemplate}
\newpage
\subsubsection{Stop election}
\begin{TestCaseTemplate}
\TestCaseIdentifier{5.1}
\TestCaseUseCase{Stop Election}
\TestCaseScenario{Primary}
\TestCaseSetup{}
\TestCaseInterface{uk.ac.glasgow.demosocs.VotingSystem.java}
\TestCaseIncludes{}
\TestCaseProcedure{Must be executed manually.}
\TestCaseInputs{date = '15/02/2012'}
\TestCaseOutcome{Date is set to 15/02/2012, and the election stops on this date.}
\end{TestCaseTemplate}

\begin{TestCaseTemplate}
\TestCaseIdentifier{5.2}
\TestCaseUseCase{Stop Election}
\TestCaseScenario{Alternative}
\TestCaseSetup{}
\TestCaseInterface{uk.ac.glasgow.demosocs.VotingSystem.java}
\TestCaseIncludes{}
\TestCaseProcedure{Must be executed manually.}
\TestCaseInputs{date = '15/02/2012'}
\TestCaseOutcome{Date is set to 15/02/2012, and the election fails to stop on this date.}
\end{TestCaseTemplate}
\newpage
\subsubsection{Publish results}
\begin{TestCaseTemplate}
\TestCaseIdentifier{6.1}
\TestCaseUseCase{Publish Results}
\TestCaseScenario{Primary}
\TestCaseSetup{Election created for level 3 class reps, votes cast and election in 'ENDED' state.}
\TestCaseInterface{uk.ac.glasgow.demosocs.VotingSystem.java}
\TestCaseIncludes{View Elections\newline
Select Election}
\TestCaseProcedure{uk.ac.glasgow.demosocs.tests.PublishResults1.java}
\TestCaseInputs{electionId = "l3ClassReps"}
\TestCaseOutcome{Class rep election results have been made available for voters to view.}
\end{TestCaseTemplate}
\newpage
\subsubsection{Nominate candidate}
\begin{TestCaseTemplate}
\TestCaseIdentifier{7.1}
\TestCaseUseCase{Nominate Candidate}
\TestCaseScenario{Primary}
\TestCaseSetup{A voter is logged in, has an election selected and that election is in the 'NOMINATIONS\_OPEN' state.}
\TestCaseInterface{uk.ac.glasgow.demosocs.VotingSystem.java}
\TestCaseIncludes{Select Election\newline
View Electorate}
\TestCaseProcedure{uk.ac.glasgow.demosocs.tests.NominateCandidate1.java}
\TestCaseInputs{guid = 'Billy'}
\TestCaseOutcome{User Billy is now listed as a potential candidate for the selected election.}
\end{TestCaseTemplate}
\newpage
\subsubsection{Accept nomination}
\begin{TestCaseTemplate}
\TestCaseIdentifier{8.1}
\TestCaseUseCase{Accept Nomination}
\TestCaseScenario{Primary}
\TestCaseSetup{Nominee is logged in and has at least one unhandled nomination.}
\TestCaseInterface{uk.ac.glasgow.demosocs.VotingSystem.java}
\TestCaseIncludes{}
\TestCaseProcedure{uk.ac.glasgow.demosocs.tests.AcceptNomination1.java}
\TestCaseInputs{accept = true}
\TestCaseOutcome{Each accepted nomination results in the voter being added as a candidate for the related election.}
\end{TestCaseTemplate}
\newpage
\subsubsection{View election}
\begin{TestCaseTemplate}
\TestCaseIdentifier{11.1}
\TestCaseUseCase{View Election}
\TestCaseScenario{Primary}
\TestCaseSetup{System initialised with the "Head of School" election and all the necessary details about it.}
\TestCaseInterface{uk.ac.glasgow.demosocs.*}
\TestCaseIncludes{}
\TestCaseProcedure{Must be executed manually.}
\TestCaseInputs{Choose to view the election “Head of School”}
\TestCaseOutcome{Details of the election, such as name, type, electorate, scheduled nomination time, start time, end time and election state are displayed.}
\end{TestCaseTemplate}
\begin{TestCaseTemplate}
\TestCaseIdentifier{11.2}
\TestCaseUseCase{View Election}
\TestCaseScenario{Alternative}
\TestCaseSetup{System initialised with the "Head of School" election and all the necessary details about it.}
\TestCaseInterface{uk.ac.glasgow.demosocs.*}
\TestCaseIncludes{}
\TestCaseProcedure{Must be executed manually.}
\TestCaseInputs{Choose to view the election "Head of School"}
\TestCaseOutcome{Details of the election are not displayed.}
\end{TestCaseTemplate}
\newpage
\subsubsection{View elections}

\begin{TestCaseTemplate}
\TestCaseIdentifier{10.1}
\TestCaseUseCase{View Elections}
\TestCaseScenario{Primary}
\TestCaseSetup{An eligible user has logged in.}
\TestCaseInterface{uk.ac.glasgow.demosocs.VotingSystem.java
\newline
uk.ac.glasgow.demosocs.Election.java}
\TestCaseIncludes{}
\TestCaseProcedure{uk.ac.glasgow.demosocs.tests.ViewElections1.java}
\TestCaseInputs{}
\TestCaseOutcome{The use should be presented with a list of elections they can take part in.}
\end{TestCaseTemplate}
\newpage
\subsubsection{Select election}
\begin{TestCaseTemplate}
\TestCaseIdentifier{11.1}
\TestCaseUseCase{Select Election}
\TestCaseScenario{N/A}
\TestCaseSetup{Login}
\TestCaseInterface{uk.ac.glasgow.demosocs.VotingSystem.java}
\TestCaseIncludes{Login}
\TestCaseProcedure{uk.ac.glasgow.demosocs.tests.SelectElection1.java}
\TestCaseInputs{electionId = "test"}
\TestCaseOutcome{The election, with ID "test", is selected.}
\end{TestCaseTemplate}
\newpage
\subsubsection{View electorate}
\begin{TestCaseTemplate}
\TestCaseIdentifier{12.1}
\TestCaseUseCase{View Electorate}
\TestCaseScenario{N/A}
\TestCaseSetup{An election is currently selected}
\TestCaseInterface{uk.ac.glasgow.demosocs.VotingSystem.java}
\TestCaseIncludes{Login}
\TestCaseProcedure{uk.ac.glasgow.demosocs.tests.ViewElectorate1.java}
\TestCaseInputs{}
\TestCaseOutcome{The electorate is displayed.}
\end{TestCaseTemplate}
\newpage
\subsubsection{Cast vote}
\begin{TestCaseTemplate}
\TestCaseIdentifier{13.1}
\TestCaseUseCase{Cast Vote}
\TestCaseScenario{Primary}
\TestCaseSetup{An eligible user has logged in and selected a candidate from an election.}
\TestCaseInterface{uk.ac.glasgow.demosocs.VotingSystem.java
\newline
uk.ac.glasgow.demosocs.Vote.java}
\TestCaseIncludes{View Election\newline
Select Election}
\TestCaseProcedure{uk.ac.glasgow.demosocs.tests.CastVote1.java}
\TestCaseInputs{}
\TestCaseOutcome{The users vote should be registered for the election.}
\end{TestCaseTemplate}
\newpage

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Testing Report for Team A}

\subsection{Test Results}

The following table displays the results of running the tests cases defined in section 3, on the code provided by Team A. A large number of these test cases fail, and as a result, reasonable effort was made to contact Team A to attempt to rectify these problems. Given the time constraint of the project, it was not possible for them to implement sufficient changes to enable a greater pass rate.

\begin{center}
  \begin{tabular}{| l | l | l | p{8cm} |}
    \hline
    \textbf{ID} & \textbf{Test Case} & \textbf{Result} & \textbf{Reason/Description} \\ \hline
    1.1 & Schedule Election & Pass & The election is created and scheduled correctly. \\ \hline
    2.1 & Edit Election & Pass & The election is edited correctly. \\ \hline
	3.1	& Open Nominations & Fail & The election status is not set, and returns null.\\ \hline	
	4.1	& Start Election (Primary) & Fail & This test fails as no election state is actually set. \\ \hline
	4.2	& Start Election (Secondary) & Fail & This test fails as when the election state is never set. It is always null. \\ \hline
	5.1	& Stop Election (Primary) & Fail & This test fails as when the election state is never set. It is always null. \\ \hline
	5.2	& Stop Election (Secondary)	& Fail & This test fails as when the election state is never set. It is always null. \\ \hline
	6.1	& Publish Results & Fail & This test fails as when the publish results test is run after an election has been created, users have been nominated and accepted nomination the results are not displayed. \\ \hline
	7.1	& Nominate Candidate & Pass	& This test passes as when a user is nominated in an election this election appears in that users list of elections in which they have been nominated. \\ \hline
	8.1	& Accept Nomination	& Pass & This test passes as the nominated user is added to candidates however there doesn’t seem to be a check that nominations are open in their voting system. \\ \hline
	9.1	& View Election (Primary) & Pass & When manually testing, the system was unable to parse the date string in the format specified by the other team however the election was still created and could be viewed. \\ \hline
	9.2	& View Election (Secondary)	& Pass & As 9.1 \\ \hline
	10.1 & View Elections & Fail & The system displays the array of elections hold by the system. However, it does not display the name and state of each election as expected. Instead it displays a name of a package with a random ID number.
	So although the the test passes because it displays information, after the manual inspection the test fails.\\ \hline
  \end{tabular}

  \begin{tabular}{| l | l | l | p{8cm} |}
    \hline
    \textbf{ID} & \textbf{Test Case} & \textbf{Result} & \textbf{Reason/Description} \\ \hline
	11.1 & Select Election & Fail & This test fails because the system takes either electorate ID or the type of election to then use it as the election ID. Otherwise the system uses the package mentioned in 10.1 as an election descriptor. None of those is acceptable as an election ID, which is used to select an election from a list provided. \\ \hline
	12.1 & View Electorate & Fail & The functionality required to perform this test is not provided by the system. \\ \hline
	13.1 & Cast Vote & Fail & This test fails, when giving one vote to the only candidate in the election then publishing results the candidate that received the vote did not win. \\
    \hline
  \end{tabular}
\end{center}

\subsection{Defect Reports}

Given the number of failed test cases, we decided to view the code in order to understand why some of these test cases may be failing. This is not an exhaustive list of defects of the system, as this would be beyond the scope of the testing exercise. Rather, this is a summary of the main defects which we believe contributed to a higher than expected failure rate.

 \begin{center}
 \begin{tabular}{| l | p{10cm} |}
    \hline
    \textbf{Test Case} & 6.1 Publish Results \\ \hline
    \textbf{Affected module} & Election Manager\\ \hline
    \textbf{Impact assessment} & High \\ \hline
 	\textbf{Nature of defect} & The results did not appear on screen. \\ \hline
 	\textbf{What happened} & No results were displayed. \\ \hline
 	\textbf{How did it occur?} & In the method to print out the results there was no code to do so. \\ \hline
 	\textbf{When did it occur?} & Publish Results method in VotingSystemStub. \\ \hline
 	\textbf{Steps to reproduce error} & Create a election; Nominate one of the predefined users; Set the current user to this user; Set the current election to the election that was created; Make them accept the nomination; Set this user to the election manager; Publish the results as this user.\\ \hline
	\textbf{Suggested fix} & Put in a print statement to print out the results that are fetched in the publish results method. \\ \hline
  \end{tabular}
\end{center}

 \begin{center}
	 \begin{tabular}{| l | p{10cm} |}
    \hline
    \textbf{Test Case} & 11.1 Select Election \\ \hline
    \textbf{Affected module} & Voting System \\ \hline
    \textbf{Impact assessment} & High \\ \hline
 	\textbf{Nature of defect} & The system uses wrong values as the election’s ID. \\ \hline
 	\textbf{What happened} & The test fails when the system compares the election ID of the currently selected election with the ID provided by the tester. \\ \hline
 	\textbf{How did it occur?} & This is because the system uses the type of an election (if the election has been created but not edited) as the election’s ID. If the election has been created and edited then the system will use the electorate ID provided in the editElection method and use it as the election’s ID. Both of the above are incorrect and cause the system not to be able to correctly identify elections.\\ \hline
 	\textbf{When did it occur?} & \\ \hline
 	\textbf{Steps to reproduce error} & Log in (Set current user); Create an election; Set the current election to the election that was created; Use getCurrentElection method to check whether the created election has been selected.\\ \hline
	\textbf{Suggested fix} & Either fix editElection method or add some sample elections to the system.\\ \hline
  \end{tabular}
\end{center}

 \begin{center}
	 \begin{tabular}{| l | p{10cm} |}
    \hline
    \textbf{Test Case} & 10.1 View Elections\\ \hline
    \textbf{Affected module} & Voting System \\ \hline
    \textbf{Impact assessment} & High \\ \hline
 	\textbf{Nature of defect} & The system displays wrong information about elections in the system. \\ \hline
 	\textbf{What happened} & An array of elections is displayed but it does not show the required information such as the name and the state of the election.\\ \hline
 	\textbf{How did it occur?} & Only one method can be used to obtain the list of elections in the system (needed to then inspect elections manually) - getElections method. However, this method returns the array of elections where each elections is described by the name of a package and a random number (for example: uk.ac.glasgow.demosocs.impl.OurPluralityElection@869470) instead of being described by the name  and the state of the election.
	There is no other way of displaying all elections currently held in the system.\\ \hline
 	\textbf{When did it occur?} & \\ \hline
 	\textbf{Steps to reproduce error} & Log in (Set current user); Create an election; Set the current election to the election that was created; Use getElections method to print a list of elections in the system.\\ \hline
	\textbf{Suggested fix} & Either change getElections method or create another method to display a list of all elections in the required way.\\ \hline
  \end{tabular}
\end{center}

 \begin{center}
	 \begin{tabular}{| l | p{10cm} |}
    \hline
    \textbf{Test Case} & 12.1 View Electorate\\ \hline
    \textbf{Affected module} & Voting System \\ \hline
    \textbf{Impact assessment} & High \\ \hline
 	\textbf{Nature of defect} & It is not possible to view electorate details.\\ \hline
 	\textbf{What happened} & Details of an electorate cannot be displayed.\\ \hline
 	\textbf{How did it occur?} & There is no method that would support displaying the details of an electorate.\\ \hline
 	\textbf{When did it occur?} & \\ \hline
 	\textbf{Steps to reproduce error} & \\ \hline
	\textbf{Suggested fix} & Create a method that display the electorate details to a user.\\ \hline
  \end{tabular}
\end{center}

 \begin{center}
	 \begin{tabular}{| l | p{10cm} |}
    \hline
    \textbf{Test Case} & 4.1, 4.2 Start Election\\ \hline
    \textbf{Affected module} & Voting System, Election\\ \hline
    \textbf{Impact assessment} & High \\ \hline
 	\textbf{Nature of defect} & No election state is ever set making it impossible to determine if an election has stopped, started or has been published.\\ \hline
 	\textbf{What happened} & A null pointer exception is thrown upon trying to check the election state.\\ \hline
 	\textbf{How did it occur?} & Upon editing an election, it’s election state is never updated.\\ \hline
 	\textbf{When did it occur?} & getElectionState in OurPluralityElection\\ \hline
 	\textbf{Steps to reproduce error} & Log in (Set current user); Create an election; Change the dates of that election to a point where it has started; Use getElectionState to check the current state of the election.\\ \hline
	\textbf{Suggested fix} & Update the election state when the election is edited.\\ \hline
  \end{tabular}
\end{center}

 \begin{center}
	 \begin{tabular}{| l | p{10cm} |}
    \hline
    \textbf{Test Case} & 5.1, 5.2 Stop Election\\ \hline
    \textbf{Affected module} & Voting System, Election\\ \hline
    \textbf{Impact assessment} & High \\ \hline
 	\textbf{Nature of defect} & No election state is ever set making it impossible to determine if an election has stopped, started or has been published.\\ \hline
 	\textbf{What happened} & A null pointer exception is thrown upon trying to check the election state.\\ \hline
 	\textbf{How did it occur?} & Upon editing an election, it’s election state is never updated.\\ \hline
 	\textbf{When did it occur?} & getElectionState in OurPluralityElection
	\\ \hline
 	\textbf{Steps to reproduce error} & Log in (Set current user); Create an election; Change the dates of that election to a point where it has ended; Use getElectionState to check the current state of the election.\\ \hline
	\textbf{Suggested fix} & Update the election state when the election is edited.\\ \hline
  \end{tabular}
\end{center}

 \begin{center}
	 \begin{tabular}{| l | p{10cm} |}
    \hline
    \textbf{Test Case} & 13.1 Cast Vote\\ \hline
    \textbf{Affected module} & Voting System, Candidate, Election\\ \hline
    \textbf{Impact assessment} & High \\ \hline
 	\textbf{Nature of defect} & The vote was not counted, also you can vote more than once.\\ \hline
 	\textbf{What happened} & Cast a vote on one candidate then published results, expecting this candidate to win but they did not win.\\ \hline
 	\textbf{How did it occur?} & Unable to determine cause\\ \hline
 	\textbf{When did it occur?} & At casting vote or publish results\\ \hline
 	\textbf{Steps to reproduce error} & Set the current user; Create an election; Nominate 2 candidates; Have them both accept; Vote for one; Publish results\\ \hline
	\textbf{Suggested fix} & \\ \hline
  \end{tabular}
\end{center}

\subsection{General observations}

The only type that can be set in the system is of type 'P' for plurality. However, this is not documented in the readme file. This meant that creating an election without this knowledge lead to all the test cases failing due to there being a null pointer exception thrown in the edit election method of VotingSystemStub. This was due to the election never being created in the first place, as it would only initialise it if its type was P. Better documentation would be useful, but additionally, some form of error other than a NullPointerException would allow the system to deal with the problem more gracefully.

From our, albeit limited, insight into the code, we do not believe that the solution provided would be sufficient to meet the functional and non-functional requirements of the project, as we interpret them. The above defects go some way to highlighting areas where functionality is broken or missing, and where attention is required.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\end{document}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%